Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Return a subscription from handleSubscription #198

Conversation

JustinKuli
Copy link
Member

Some of the additional checks will need pieces of information from the Subscription. Converting it before returning it (as opposed to using an Unstructured) should help reduce other error checking.

@JustinKuli
Copy link
Member Author

I think this might be useful for @JeffeyL's #196 and @zyjjay's #195.

}

desiredSub.SetGroupVersionKind(subscriptionGVK) // Create stripped this information

// Now it should match, so report Compliance
err = r.updateStatus(ctx, policy, createdCond("Subscription"), createdObj(desiredSub))
if err != nil {
return fmt.Errorf("error updating the status for a created Subscription: %w", err)
return desiredSub, fmt.Errorf("error updating the status for a created Subscription: %w", err)
}
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think returning a subscription inside of the logic that handles the enforce remediationAction type would be useful for future handler functions. It would make sense for this function to return a subscription only if it was created successfully on the cluster.

}
}

return nil
return desiredSub, nil
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think returning something like nil, nil would be better here if we can return the subscription in the enforce case. Then in my PR, I could use the return value to determine if the desired subscription exists on the cluster (nil vs a subscription object) and skip a call to r.DynamicWatcher.Get to retrieve the subscription.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It's possible... but I think that if inform mode returned nil, nil here, it would artificially limit some of the information we can get. For example, it is generally possible to check if the CatalogSource specified in the policy exists on the cluster, even if the Subscription doesn't exist.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I might be overlooking something but is the point of this to reduce calls to buildSubscription?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Mostly. This would reduce calls to buildSubscription and dynamicWatcher.Get for the Subscription.

This can also return the "merged" subscription, regardless of inform/enforce, which hypothetically could be useful for some other healthcheck... I don't see a need for that yet, but it feels like it's easy enough to "do it right" now, so we don't have to worry about it later. For example if some other check used the channel in the subscription, this function would always return the desired setting based on the policy, which is what I think the user would be expecting.

Copy link
Contributor

@zyjjay zyjjay Feb 5, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I see, I think that would be useful in general. For my specific case I'm only calling dynamicWatcher.Get on a catalogsource when the subscription doesn't exist yet, so I might need to end up calling dynamicWatcher.Get on the subscription anyways in handleCatalogSource because the return values of handleSubscription doesn't seem to indicate whether or not a subscription exists on the cluster. I will look into ways to work around this on my end.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should mention that I'm specifically thinking about the inform case.

Some of the additional checks will need pieces of information from the
Subscription. Converting it before returning it (as opposed to using an
Unstructured) should help reduce other error checking.

Signed-off-by: Justin Kulikauskas <jkulikau@redhat.com>
@zyjjay
Copy link
Contributor

zyjjay commented Feb 5, 2024

/lgtm

}

mergedSub := new(operatorv1alpha1.Subscription)
if err := runtime.DefaultUnstructuredConverter.FromUnstructured(merged.Object, mergedSub); err != nil {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I just checked and I don't believe this will produce an error if there are unknown fields (e.g. version drift of different OLM versions). So this looks to be safe if you are just reading from it.

Copy link

openshift-ci bot commented Feb 5, 2024

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: JustinKuli, mprahl

The full list of commands accepted by this bot can be found here.

The pull request process is described here

Needs approval from an approver in each of these files:

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

@openshift-merge-bot openshift-merge-bot bot merged commit 934c69b into open-cluster-management-io:main Feb 5, 2024
4 checks passed
@JustinKuli JustinKuli deleted the useful-subscription-return branch July 25, 2024 13:41
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants